This branch currently has no diff against #114 (git diff between the two heads is empty), so the streaming change mentioned in the description doesn't seem to be pushed yet.

On the change itself: I flagged the buffering divergence in #114 as a behavioural note rather than a performance problem. The marker fallback path only handles plugin marker POMs (<1KB), checksum sidecars (~40 bytes) and maven-metadata.xml (a few KB). The streaming bypass in ProxyCached exists for things like npm packuments that can be megabytes; for these files buffering is fine. I don't think it's worth the extra code, so feel free to close this.

If you do still want to pursue it, please either retarget the base branch to gradle-plugin-fallback-support or wait until #114 merges and rebase, so the diff shows only the streaming change rather than all of #114.

Thanks for pushing the actual change, had another look now #114 is merged.

The title/description frame this as a streaming optimisation but most of the diff is a behaviour change: the plugin-portal fallback is now gated to Gradle plugin marker coordinates only (artifact ends in .gradle.plugin and matches the group). The streaming part in proxyMetadataStreamWithFallback is fine but isn't really buying anything since marker metadata files are a few KB at most.

The gating introduces a regression. handleDownload still falls back unconditionally on 404, so a plugin's implementation jar/pom resolve fine, but their checksum sidecars route through handleMetadata → shouldFallbackToPluginPortal, which returns false for non-marker coordinates and goes to ProxyCached against the primary only. For portal-only plugins that means the proxy serves the jar but 404s the .sha1. com.gradle.publish:plugin-publish-plugin:1.2.1 is one example: Central 404s plugin-publish-plugin-1.2.1.jar.sha1, the portal has it. The deleted TestMavenHandler_GradlePluginImplementationMetadataFallback covered this case; removing it instead of updating it is what hid the break.

I like the idea of skipping the second round-trip for ordinary Central misses, but I can't see a way to identify implementation artifacts from the path alone, so the gate as written breaks portal-only plugins.

A few smaller things:

• The bare .pom / .module checks in isPluginPortalFallbackFile are unreachable from handleMetadata since isMetadataFile doesn't match those extensions; they go through handleDownload. The "marker pom" unit test only passes because it calls shouldFallbackToPluginPortal directly.
• TestMavenIsMetadataFile was removed but isMetadataFile is still in use; would be good to keep that test and add the new one alongside.
• pluginPortalURL is built twice in handleMetadata.
• setupTestProxy was widened to testing.TB but nothing uses it as a *testing.B.
• Typo "optymization" in the title/branch.

Up to you whether to close this or rework it. If you want to keep going, I'd suggest retitling/redescribing around the fallback gating (since that's the real change), reinstating the implementation-metadata test, and figuring out what to do about portal-only implementation checksums. Happy to discuss approaches on that last point.